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Development  and  Use  of  PROPHET  Life  Cycle  Cost  Model 


BACKGROUND 


All  of  us  are  living  during  the  development,  maturation,  and  aging  of  certain 
technological  and  social  systems,  their  influences  on  each  other,  and  their  synthesis. 

Many  of  us  do  not  recognize  the  significance  of  the  synthesized  products  until  after  the 
combining  event  has  passed.  This  paper  describes  the  result  of  the  three  most 
significant  trends  in  cost  estimating  of  the  past  twenty-five  years.  These  trends  include  the 
low  cost  availability  of  linked  spreadsheets,  the  advent  of  more  powerful  processors  in 
personal  computers,  and  the  dissemination  by  the  Department  of  Defense  of 
comprehensive  guidance  on  a  disciplined  approach  to  cost  estimating  and  standardized 
estimate  report  contents.  These  three  trends  since  1991  have  opened  a  new  era  in  cost 
estimating  for  acquisition  and  support  of  major  defense  systems. 

f 

Command  Need 

« 

In  early  1991  the  three  fundamental  trends  cited  in  the  opening  paragraph  led  to  the 
development  of  the  PROPHET  Life  Cycle  Cost  Model  (LCCM).  Other  influences 
consisted  of  a  developing  awareness  in  the  Naval  Undersea  Warfare  Center  Division 
Newport  (NUWCDIVNPT)  of  the  need  to  integrate  cost  estimating  in  the  system  design 
process,  and  the  assignment  of  new  responsibilities  to  NUWCDIVNPT.  The  synthesis  of 
these  forces  is  illustrated  in  Figure  1 . 

I  For  more  than  a  decade,  NUWCDIVNPT  (and  earlier,  NUSC)  has  had  an 

expanding  capability  in  analyzing,  predicting,  and  tracking  reliability  of  system 
components,  and  using  reliability  differences  to  select  among  system  and  support 
alternatives.  The  NUWCDIVNPT  engineers  in  the  Reliability  Branch  could  assign  costs  to 
the  system  components  being  analyzed  and  could  readily  appreciate  the  significant 
differences  in  predicted  life  cycle  costs  (LCC)  which  occurred  with  differences  in  reliability. 
Utilizing  the  Naval  Sea  Systems  Command  (NAVSEA)  TIGER  Program^  installed  on  a 
Cray  super  computer  in  their  analyses  of  system  reliability,  they  recognized  and 
recommended  that  the  scope  of  the  analyses  be  expanded  to  include  costs,  and  that  the 
cost  estimating  capability  be  integrated  with  the  TIGER  Program.  However,  integration 
with  TIGER  in  the  Cray  meant  expensive  development  of  code,  as  well  as  the 
development  of  reliable  cost  estimating  routines  which  would  be  expressed  in  the  code. 

’  Developed  and  maintained  bv  Dr.  P.  J.  Hartman,  NAVSEA  Reliability  and  Maintenance  Engineering 
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DEVELOPMENT  AND  USE  OF  PROPHET  LIFE  CYCLE  COST  MODEL 

In  mid-1991  the  Naval  Undersea  Warfare  Center  Division,  Newport,  initiated  an  effort  to 
estimate  the  costs  of  notional  electronic  systems.  Life  cycle  cost  and  particularly  Engineering 
and  Manufacturing  Development  (E&MD)  phase  cost  were  considered  to  be  of  equal  importance 
to  performance  in  evaluating  the  several  candidate  electronic  systems.  Adding  emphasis  to  the 
need  for  reliable  E&MD  cost  estimates  was  the  inclusion  of  existing  and  partially  modified 
existing  subsystems  and  cabinets  in  the  list  of  candidate  systems. 

Since  development,  PROPHET  has  been  used  extensively  to  estimate  and  compare  the  costs  for 
the  E&MD  phase  for  different  electronic  system  configurations.  Included  in  these  comparisons 
have  been  the  costs  associated  with  gaps  in  production,  modifications  to  cabinets  and  displays, 
new  hardware  subsystems,  alternative  schedules,  and  changes  in  integration  and  assembly 
routines.  Validation  of  the  model  is  continuing. 

Richard  Barclay,  Jeffrey  Feaster,  Mr.  Richard  Barclay 

Robert  Craig  and  William  Hugo  Commander 

Naval  Undersea  Center  Division-Newport 
ATTN:  Mr  Richard  Barclay,  Code  442,  Bldg  166TT 
Newpoi.,  Rhode  Island  02841 
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Proposed  Approach  Solution 

NUWCDIVNPT  engineers  examined  the  requirements  and  resources  for  the 
development  of  a  cost  model.  They  considered  the  cost  estimating  personnel  skills 
(existing  or  acquired  through  training)  for  laboratory  staff  to  accomplish  the  cost  estimates, 
the  characteristics  and  availability  of  tools  (models,  databases)  they  would  need  to  use, 
the  time  available  to  accomplish  meaningful  estimates  of  priority  electronic  systems,  and 
the  limited  funding  and  time  available.  The  examination  also  included  study  of  the 
qualifications  of  known  support  contractors  that  could  assist  NUWCDIVNPT  personnel  in 
the  development  of  a  model. 

Because  of  the  time  constraint  and  the  limited  funds  available  for  development  of  a 
tool,  coupled  with  the  equally  demanding  requirements  for  openness,  ease  of  operation, 
and  tailoring,  it  was  decided  to  use  commercial  spreadsheets  rather  than  create  a  model 
in  code  or  a  higher  order  language.  The  results  of  the  analysis  indicated  that  the  lowest 
cost,  quickest,  and  most  effective  route  to  develop  a  prototype  tool  for  estimating  the  LCC 
of  electronic  systems  and  to  accomplish  the  necessary  estimates  would  be  to  develop  the 
prototype  tool  in  a  commercial  spreadsheet.  A  spreadsheet  was  inexpensive,  a  fairly 
large  number  of  people  in  and  out  of  the  Reliability  Branch  were  skilled  in  their 
development  and  use,  many  cost  elements  could  be  included,  the  algorithms  (cell 
formulas)  and  mathematical  structure  would  be  very  visible  and  could  be  easily 
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programmed  to  respond  to  changed  inputs,  and  they  could  easily  be  manipulated  to 
generate  different  reports.  A  spreadsheet  tool  or  model  could  be  documented,  easily 
operated,  and  easily  tailored  to  the  evolving  needs  of  NUWC  or  the  systems  under 
consideration. 

In  mid-1991  when  development  commenced,  it  was  believed  that  Microsoft 
EXCEL2,  version  3.0,  and  the  Macintoshs  operating  environment  (Ilex)  offered  learning 
curve  and  development  speed  advantages  over  Lotus^  and  MS/DOS^  personal 
computers.  This  decision  did  speed  development  time,  and  has  been  non-critical 
subsequently  as  the  tool  has  been  moved  to  the  MS/OOS  environment  in  an  Intel 
“486/33"  and  upgraded  to  EXCEL,  version  4.0,  for  still  greater  operating  speed,  and 
without  any  problems.  The  MS/DOS  version  also  has  been  easily  translated  back  to  the 
Macintosh  operating  system  in  EXCEL,  v.  4.0. 

It  was  determined  that  the  structure  of  the  model  should  be  in  compliance  with  the 
then  newly  issued  Defense  Acquisition  Management  Policies  and  Procedures. 
Department  of  Defense  Instruction  (DoD  INST)  5000.2  and  the  long-established  Military 
Standard  Work  Breakdown  Structures  for  Defense  Materiel  Items.  (MIL- STD-881  A),  and 
would  be  developed  in  two  phases.  Phase  I  of  the  proposed  approach  would  involve 
development  of  the  tool,  and  a  subsequent  Phase  II  would  center  on  refining  the  tool  and 
integrating  it  with  the  TIGER  model. 

During  the  early  stages  of  development  the  tool  was  simply  referred  to  as  “LCCM" 
but  as  NUWCDIVNPT  engineers  became  aware  of  the  capabilities  in  the  prototype  tool 
and  the  growth  possibilities  it  held,  it  was  decided  to  refer  to  the  model  as  “PROPHET. 


ENVIRONMENT 

The  environment  in  which  PROPHET  must  operate  is  defined  by  the  overlapping 
regions  of  the  DoD  system  acquisition  process,  NUWCDIVNPT  life  cycle  responsibilities 
and  tasks,  and  life  cycle  cost  model  requirements  imposed  by  NUWCDIVNPT.  These 
regions  are  depicted  in  Figure  2. 


DoD  System  Acquisition  Process 


DoD  INST  5000.2  prescribes  a  systematic  approach  to  acquisition  of  defense 

systems,  with  a  series  of  Milestones  at  major  decision  points.  Defense  Acquisition  _ 

Management  Documentation  and  Reports  Manual  (DoD  5000.2-M)  describes  the  reports 
and  supporting  data  required  in  implementing  an  acquisition  program  and  passing  the  cra&j 
Milestone  decision  points.  OSD  Cost  Analysis  Improvement  Group  fCAIGl  Directive  tab 
(DoD  DIR)  5000.4  updates  the  charter  of  the  Office  of  the  Secretary  of  Defense  Cost  'ot^'nced 

Analysis  Improvement  Group  (OSD  CAIG),  and  defines  the  relationships  among  the  - 


2  Excel  is  a  trademark  of  Microsoft  Corporation 
2  Macintosh  is  a  trademark  of  Apple  Corporation 
^  Lotus  is  a  trademark  of  Lotus  Development  Corporation 
5  MS/DOS  is  a  trademark  of  Microsoft  Corporation 
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Figure  2,  PROPHET  Environment 


CAIG  cost  estimates  and  cost  estimates  by  the  DoD  Component  (CCA)  and  Program 
Office  (POE).  Cost  Analysis  Guidance  and  Procedures  Manual  (DoD  5000.4'M)  provides 
guidance  on  collecting  and  preserving  the  data  inputs  and  model  algorithms,  and  the 
content,  scope,  and  presentation  of  cost  analyses  and  estimates.  The  DoD  environment 
influencing  cost  estimates  is  depicted  in  Figure  3.  Together  the  cited  instruction,  directive, 
and  manuals  define  the  structure  and  content  of  the  cost  estimate  reports  needed  to  make 
informed  and  responsible  decisions  at  the  Milestones  in  the  acquisition  of  a  defense 
system.  It  is  interesting  to  note  that  development  of  PROPHET  commenced  soon  after 
issuance  of  the  first  two  documents  and  well  before  promulgation  of  the  detailed  DoD 
5000.4-M  manual.  Designed  in  accommodation  to  Product  Improvement,  careful 
adherence  to  Parts  4  and  15  of  DoD  Manual  5000.2-M  and  MIL-STD-881A,  and 
dedication  to  comprehensive  preservation  of  the  estimate  inputs,  however,  permits 
PROPHET  to  operate  in  compliance  with  the  newer  directives,  including  MIL-STD-881B, 
with  minimum  changes  and  effort. 

The  effect  of  the  documents  directly  shapes  the  output  of  a  cost  estimate  and 
indirectly  how  an  estimate  will  be  accomplished.  For  example.  Page  C-1  of  Part  4  (the 
Integrated  Program  Summary)  of  DoD  Manual  5000.2-M  prescribes  how  the  high  level 
output  of  a  cost  estimate  will  look  for  the  Development  Phase  (Concept  Exploration, 
Demonstration  and  Validation  and  E&MD)  and  what  categories  of  cost  will  be  summarized 
in  it  in  constant  and  then-year  dollars  for  each  of  the  requisite  fiscal  years.  Figure  4  is  an 
illustration  of  a  PROPHET  output  for  one  page  of  an  IPS.  Knowing  the  required  output 
format,  it  is  theoretically  possible  to  construct  a  model  which  will  produce  all  the  necessary 
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Figure  3,  DoD  Cost  Estimating  Environment 
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divisions  of  cost  from  a  single  input  value.  However,  we  don’t  suggest  that’s  the  way 
PROPHET  is  constructed. 


Page  2  of  Attachment  1  to  Part  15  of  DoD  Manual  5000.2-M  prescribes  the  format 
and  content  of  a  Program  Office  Estimate  (POE)  for  the  E&MD  Phase  with  greater 
granularity  than  shown  in  the  IPS;  see  Figure  5.  It  is  interesting  that  the  cost  elements  are 
slightly  different  than  the  categories  described  in  MIL-STD-881 B.  PROPHET  was 
designed  to  produce  outputs  in  compliance  with  the  DoD  Manual  5000.2-M  guidance,  but 
due  to  the  dimensions  in  PROPHET  it  also  can  generate  reports  in  a  MIL-STD-881  B 
stnjcture. 


DoD  Manual  5000.4-M,  in  Table  2-2,  directs  a  slightly  different  breakout  of  cost 
elements  for  presentation  to  a  CAIG  than  does  DoD  Manual  5000.2-M.  These  differences 
are  primarily  in  the  Support  and  Services  area.  The  baseline  PROPHET  has  not  been 
amended  as  yet  to  provide  totals  for  this  revised  list  of  cost  elements  due  to  funding 
constraints,  but  a  special  purpose  modification  of  PROPHET  has  been  developed  and 
operated  which  does  provide  these  details. 

DoD  Manual  5000.4-M  also  includes  guidance  on  the  schedule  for  submission  of 
cost  estimates  and  supporting  documentation  to  the  CAIG.  A  large  portion  of  this  manual 
promulgates  clear  definitions  of  what  should  be  included  in  a  Cost  Analysis  Requirements 
Description  (CARD),  and  the  type  and  amount  of  justification  needed  for  Cost  Estimating 
Relationships  (CERs)  contained  in  an  estimate.  The  guidance  in  this  manual  is 
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Figure  4,  Sample  PROPHET  Output 


Total  Davdopmant  Phase  |  |  111.1  «17.2  122.9  «2e.e  127.2  $37.0  $39.0  $42.2  $0.0  $223.1 


Figure  5,  Program  Office  Estimate  Structure 
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Military  Construction 
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Military  Personnel 


Total  Research  and  Development  Cost  Category 
Number  of  Units 


considered  a  very  significant  advancement  in  the  cost  estimating  discipline. 
NUWCDIVNPT  Life  Cycle  Responsibilities  and  Tasks 

The  second  region  in  which  PROPHET  must  operate  is  governed  by  the 
organizational  responsibilities,  relationships,  and  schedules  for  development  of  new 
electronic  systems  in  the  Navy  in  general,  and  NUWCDIVNPT,  specifically.  Primarily  this 
dictates  the  scope  and  content  of  tailored  cost  estimate  reports,  absolute  configuration 
control  and  archiving  of  inputs  and  outputs,  and  rapid,  near  real  time  operation.  For 
example,  it  is  helpful  to  some  of  the  development  engineers  to  input  two  alternative 
system  configurations  and  compare  the  bottom-line  total  development  costs  of  the  two 
configurations,  NOW.  Now  is  often  defined  as  less  than  five  minutes.  Figure  6  attempts  to 
illustrate  the  conditions  of  this  second  region. 


Figure  6,  NUWCDIVNPT  Estimating  Environment 
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Quite  frequently  NUWCDIVNPT  must  respond  to  requests  from  NAVSEA  or 
OPNAV  for  cost  estimates  of  alternative  systems.  Engineers  must  prepare  the  input 
parameters  for  the  alternatives,  which  can  take  anywhere  from  a  few  minutes  to  review  the 
existing  system  inputs  to  verify  absence  of  changes,  to  several  weeks  to  define  the  new 
alternatives.  Quite  often,  the  initial  estimate  will  trigger  a  new  set  of  questions  and 
modifications  to  the  original  inputs,  followed  by  a  sequence  of  further  estimates. 

The  NUWCDIVNPT  region  also  establishes  the  equipment  and  software 
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environment  in  which  the  model  will  operate.  The  prototype  PROPHET  is  currently  being 
maintained  and  operated  by  Reliability  Branch  engineers  on  486/66  personal  computers 
with  MS/DOS  5.0  and  Windows  3.1®,  with  the  Branch  engineers  responding  to  requests 
from  development  engineers.  The  requests  for  an  estimate  can  be  in  the  form  of 
telephone  calls,  facsimile  transmissions,  personal  visits,  or  memos  to  the  Reliability 
Branch,  or  as  a  result  of  conference  action  items.  Ultimately,  it  is  envisioned  that 
PROPHET  will  be  available  to  any  engineer  in  the  laboratory  on  a  network. 

In  summary,  the  DoD  Acquisition  Process  region  can  be  thought  of  as  a  disciplined 
approach  to  the  conduct  of  a  cost  estimate,  while  the  NUWC  region  is  where  the 
disciplined  approach  must  distinguish  among  concepts  and  system  architectures 
competing  for  limited  funds.  The  third  region,  specific  model  requirements,  defines  how 
the  approach  can  succeed  in  the  competitive  arena. 

Life  Cycle  Cost  Model  Requirements 

Clearly,  the  first  two  regions  set  the  parameters  for  PROPHET  outputs,  establish 
the  operating  environment,  and  to  a  lesser  degree,  prescribe  the  performance  schedule. 
What  are  the  inputs  to  PROPHET,  and  what  is  the  is  the  operating  rule,  algorithm,  or 
structure  of  PROPHET?  Figure  7  contains  a  block  diagram  of  this  region. 


Figure  7,  The  PROPHET  Region 


®  Windows  is  a  trademark  of  Microsoft  Corporation 
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PROPHET  was  a  prototype  tool  which  had  to  be  completed  in  a  short  period  of 
time.  Because  of  the  need  to  have  visibility  on  the  internal  operations  of  the  model  for 
training  and  future  integration  purposes  we  decided  to  construct  the  model  in  a 
commercial  spreadsheet.  The  formulas  in  the  series  of  cells  in  the  spreadsheet,  even 
though  lengthy,  are  more  auditable  than  arcane  code  by  the  ultimate  user  engineers. 

In  developing  the  model  we  had  a  choice  of  limiting  the  inputs  to  a  few  key 
parameters  or  to  including  ail  parameters  which  influenced  cost  and  which  we  could 
identify  with  reasonable  confidence.  We  elected  to  include  all  those  parameters  which  we 
could  reasonably  identify,  more  than  1 ,200  for  the  entire  model.  Our  concern  was  that  if 
we  did  not  include  many  parameters  we  might  not  capture  all  the  real  world  cost  drivers  in 
the  model.  Subsequently  these  inputs  have  turned  out  to  be  a  good  match  for  the 
contents  of  the  CARD  described  in  DoD  Manual  5000.4-M.  We  consider  it  important  that 
the  model  use  the  same  system  configuration  data  and  level  of  detail  as  tne  TIGER 
Program  to  support  tradeoff  studies.  The  type  of  inputs  for  the  model  are  listed  in  Table  1 
and  described  in  greater  detail  in  a  following  section. 


Table  1 

Type  of  PROPHET  inputs 


Schedules 

Shore  and  Trainer  System  Quantities 
Crew 

Government  Work  Year  Costs 
Contractor  Indirect  Rates 
Hardware  Units  and  Costs 
Support  Software  Size  and  Languages 
ECP  and  ECP  Costs 

Lowest  Replaceable  Unit  Annual  Failures 
Training  Costs 
Escalation  Factors 
Scalars 

Software  Support  Activity 


System  Quantities 
Government  Facilities 
Government  Staffing 
Contractor  Labor  Rates 
Learning  Factors 

System  Software  Size  and  Languages 

Labor  to  Material  Ratios 

Overhauls 

Major  Modifications 

Support  and  Test  Equipment 

Risk  Factors 

Expenditure  Profiles 
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The  requirements  for  the  model  were  based  not  only  on  DoO  reporting 
requirements,  but  on  the  ultimate  objective  of  operating  a  model  which  could  be  integrated 
with  TIGER  and  included  capability  characteristics.  Because  of  the  limited  amount  of  time 
which  NUWCDIVNPT  personnel  would  have  to  become  familiar  with  the  model,  it  was 
important  that  the  model  be  easy  to  operate  and  that  inputs  be  readily  relatable  to  outputs. 
For  example,  a  change  in  the  number  of  annual  failed  parts  shouL  wwow  up  in  a  change  of 
output  costs  for  depot  rework  costs  and  replenishment  spares. 

Specific  requirements  for  the  model  included  the  capability  to  estimate  phase  costs 
for  development  and  assembly  of  demonstration  hardware  and  software,  engineering 
development  models,  low  rate  and  full  rate  production  systems,  arranged  by  budget 
categories  and  fiscal  years,  and  including  both  contractor  and  Government  costs. 

Other  specific  requirements  for  the  model  included  the  capability  to  estimate  life 
cycle  costs  sensitive  to  differences  in  system  design,  mission  parameters,  and  logistic 
factors.  Model  requirements  also  included  measurement  of  the  cost  impacts  of  alternative 
system  configurations,  component  reliability,  mission  lengths  and  frequency,  sparing 
levels,  and  support  policies,  crew  skills  and  training,  maintenance  personnel  skills  and 
quantities,  mean  time  to  repair  failed  items,  depot  capabilities  and  work  loads,  and 
software  support  activity  staffing. 

In  order  for  the  model  to  accept  the  stated  inputs  and  produce  the  required  outputs 
in  a  consistent,  repeatable  manner,  the  model  must  be  constructed  in  a  logical 
arrangement  and  contain  a  mechanism  or  algorithm.  The  model  arrangement  and 
mechanism,  or  more  properly,  the  mathematical  structure,  algorithms,  and  CERs  in  the 
model  and  the  methodology  embraced  are  described  in  following  sections. 


METHODOLOGY 

The  requirement  to  generate  different  detailed  outputs  and  the  need  to  accept 
many  input  values  led  to  the  selection  of  a  hybrid  methodology  in  the  context  of  a  cost 
engineering  matrix.  That  is,  the  model  is  built  up  from  low  level  algorithms  and  CERs  at 
the  cost  element  or  work  package  level.  These  low  level  algorithms  and  CERs  within  the 
model  were  analogous,  parametric,  or  cost  engineering  as  most  appropriate  for  the 
available  data  or  the  cost  element.  These  multiple  low  level  CERs  were  arranged  in  a  cost 
engineering  matrix  based  on  MIL-STD-881A  supplemented  by  the  cost  elements  in  DoD 
Manual  5000.2-M. 

Many  of  the  original  CERs  utilized  in  the  model  came  from  those  developed  by 
NAVSEA  06  for  sonar  systems  and  shipboard  electronic  systems,  or  from  those  derived 
by  the  authors  from  contractor  data.  Subsequently,  some  of  the  CERs  have  been 
replaced  by  ones  developed  by  NUWCDIVNPT  from  recent  submarine  warfare  systems. 
The  need  to  improve  the  CERs  is  recognized  and  refinement,  calibration,  and 
documentation  of  the  CERs  is  continuing  as  a  priority  matter.  It  is  important  to  emphasize 
that  the  structure  of  the  model  permits  update  and  replacement  of  the  CERs. 
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PROPHET  ARCHITECTURE 


Mathematical  Structure  and  Dimensions 

The  fundamental  mathematical  structure  of  PROPHET  is  illustrated  in  Figure  8. 
This  structure  is  repeated,  either  completely  or  partially,  throughout  all  the  phase 
spreadsheets  in  the  model.  As  noted  below  all  of  the  input  values  and  computed  statistics 
are  contained  in  one  spreadsheet.  CERs  are  used  in  all  spreadsheets;  some  CERs  are 
used  in  more  than  one  spreadsheet. 

We  were  able  to  create  in  the  model  all  of  the  important  dimensions  needed  in  a 
cost  model  for  a  defense  system.  The  dimensions  contained  in  PROPHET  are: 

Life  Cycle  Phase  (DoD  5000.2  defined) 

Fiscal  Year 

Appropriation  Category  (RDT&E,  OPN,  O&MN,  MPN,  etc.) 

Expending  Organizations  (Contractor  or  specific  Government  agency) 
Nature  of  the  Cost  (Recurring  or  non-recurring) 

Cost  Category  (Personnel,  travel,  minor  procurement) 

Contract  Serial  (Each  one  of  a  series  of  production  contracts) 


Figure  8,  PROPHET  Mathematical  Structure 


(  System/Cabinet  UC1/T1 

X  Qty  X  Learning  x  Schedule) 

( 

+  ^  X  Support/Services  CERs) 

(  +  Software  Development  CER  x  Schedule  ) 


+  Govt  CERs  X  Schedule  ) 

(  +  Software  Maintenance  CERs  x  Schedule] 


Total  Life  Cycle  Costs,  by  Phases,  Category,  and  Nature 


General  Arrangement 

Assuming  use  of  a  commercial  spreadsheet  application,  such  as  EXCEL,  and  the 
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requirement  tor  many  inputs  and  ditterentiy  dimensioned  outputs  for  each  phase  and  tor 
special  purposes,  it  is  more  efficient  to  use  linked  spreadsheets  than  to  put  the  entire 
model  in  one  spreadsheet.  Multiple,  modular  spreadsheets  also  facilitate  tailoring  of  the 
model  to  fit  different  systems.  This  is  the  approach  selected  for  PROPHET.  A  view  of  the 
high  level  architectural  concept  of  PROPHET  is  provided  in  Figure  9. 

With  multiple  spreadsheets  it  is  important  to  limit  all  user  input  values  to  one 
spreadsheet  to  eliminate  redundant  insertion,  user  confusion  over  multiple  identical  inputs, 
and  to  simplify  the  user  task  of  operating  the  model.  Consequently,  PROPHET  has  all 
inputs  in  one  master  spreadsheet,  called  LCCM  IN. 

Each  life  cycle  phase  has  at  least  one  spreadsheet  focused  on  that  phase.  Most 
phases  have  several  spreadsheets,  with  one  estimating  Prime  Mission  Equipment  costs, 
another  estimating  System  Integration  and  Asser?h!y  and  Software  costs,  two  other 
spreadsheets  estimating  Contractor  Support  and  Ser/ice  costs,  and  several  more 
estimating  the  cost  of  each  Government  agency  involved  in  the  program.  There  are  also 
one  or  more  spreadsheets  for  collecting  and  summarizing  costs  for  output  reports. 
Currently,  PROPHET  contains  63  spreadsheets,  but  an  “advanced  PROPHET  will  reduce 
that  number  to  17  including  the  Integrated  Summary  Report. 


E&MD  Phase  Structure 


The  E&MD  Phase  consists  of  seven  spreadsheets  for  estimating  costs  and  five 
collector  spreadsheets  in  an  arrangement  depicted  in  Figure  10.  Each  spreadsheet 
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Figure  10,  PROPHET  E&MD  Architecture 


contains  a  section  at  the  top  where  input  values  and  computed  data  from  LCCM  IN  is 
linked  into  cells.  It  is  these  “linking  cells”  which  are  referenced  in  the  formulas  in  the  body 
of  the  spreadsheets  for  estimating  the  costs  of  specific  WBS  elements.  A  subsequent 
version  of  PROPHET  eliminates  this  two-step  linking  process  and  references  named 
LCCM  IN  values  in  the  body  of  the  phase  spreadsheets.  The  arrangements  within  the 
EMD_PME1  and  EMD_PME2  (MS/DOS  version  nomenclature)  spreadsheets  are 
illustrated  in  Figures  1 1 A  and  1 1 B.  The  structure  and  data  flow  from  hardware  through 
software  to  system  integration  is  visible.  WBS  element  numbers  in  the  current  model  were 
inserted  as  generic  identifiers  only  and  do  not  represent  any  specific  system  WBS.  The 
WBS  identifiers  can  be  changed  to  represent  the  specific  WBS  of  the  system  being 
estimated. 

Examples  of  the  structure  and  flow  in  the  Contractor  Support  and  Services  E&MD 
spreadsheets  are  shown  in  Figures  12A  and  12B.  The  costs  for  each  element  are 
estimated  separately  and  then  collected  at  the  bottom  of  the  spreadsheets.  The  work 
package  groups  are  visible  in  the  figure  outlines,  and  their  similarity  to  the  DoO  Manual 
5000.2-M  cost  elements  can  be  traced. 

Similarly,  the  structure  of  the  Government  spreadsheets  is  depicted  in  Figure  13. 
All  of  the  values  and  computed  statistics  in  these  E&MD  spreadsheets  come  from  the  links 
to  LCCM  IN. 
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Figure  11  A,  E&MD  PME1  Arrangement 


Linked  Data  from  LCCM  IN 

Prime  Mission  Equipment  (CFE)  in  base  year  $,  by  years 
Contingency/Risk  $  for  PME,  by  years 


Figure  1 1 B,  E&MD  PME  2  Arrangement 

Linked  Data  from  LCCM  IN 

Software  Development  for  new  system  SLOC,  by  years 

Software  Development  for  modified  utility  SLOC,  by  years 

System  Integration  Requirements  and  Planning 

System  Production  Design 

Production  Process  Design 

Inspection,  Setup,  and  Removal 

Integration  Activities 

integration/production  Test  Site 

Acceptance  Test 

Design  Maintenance 

System  Integration  &  Assembly  (SI&A)  Administrative  Engineering 
SI&A  Tooling 

Prime  Mission  Equipment  (GFE) 

GFI/Software  for  GFE 
Auxiliary  Hardware/Software 

Maintenance  Assistance  Modules 
Engineering  Changes 
Software  Maintenance 

Packaging,  Handling,  Storage  &  Transportation 
Contingency/Risk  $,  by  years 
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Figure  12A,  E&MD  SS1  Arrangement 


Linked  Data  from  LCCM  IN 

Systems  Engineering 
Program  Management 
System  Test  and  Evaluation 
Integrated  Logistic  Support 
Data 
Training 

Contingency/Risk  Factors 


Figure  12B,  E&MD  SS2  Arrangement 


Linked  Data  from  LCCM  IN 

Installation 

Deployment 

Facilities 

Support  Equipment 
Contingency/Risk  Factors 
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Figure  13,  E&MD  Government  Arrangement 


Linked  Data  from  LCCM  IN 

Systems  Engineering 

Program  Management 

System  Test  and  Evaluation 

Integrated  Logistic  Support 

Training 

Installation 

Deployment 

Facilities 

Support  Equipment 
Contingency/Risk  Factors 


INPUTS 

Categories 

The  different  categories  of  inputs  in  PROPHET  are  listed  in  Table  1 ,  shown 
previously.  The  number  of  input  values  within  a  category  can  vary  from  one  to  several 
dozen.  One  example  of  an  input  is  the  fiscal  year  in  which  the  third  production  contract 
option  is  exercised.  Another  example  is  the  number  of  Sonarman,  Third  Class  in  the  crew 
of  a  submarine  or  ship.  A  third  example  is  the  percentage  of  fabrication  labor  involved  in 
the  second  year  of  a  contract.  All  of  these  Input  values  can  be  change  d  from  run  to  run. 
The  sum  total  of  all  these  inputs  represents  the  value  portion  of  the  CARD  for  that 
particular  run.  Printing  LCCM  IN,  the  input  spreadsheet  and  archiving  it  electronically  is  a 
means  of  preserving  the  input  values  for  a  cost  estimate  of  a  specific  system  or  program 
alternative. 

The  inputs  are  used  in  CERs  and  estimating  algorithms  in  the  dependent  phase 
spreadsheets  to  develop  the  cost  of  individual  elements. 

Switches 

The  input  spreadsheet,  LCCM  IN,  also  contains  several  switches.  These  are 
used  to  control  which  of  two  or  more  input  values,  functions,  or  CERs  are  used  in  any 
specific  run  of  PROPHET.  For  example,  the  model  contains  a  switch  to  select  either  one 
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of  two  learning  curves,  Cumulative  Average  or  Unit  Cost.  Another  switch  selects  between 
use  or  non-use  of  concurrent  engineering  by  the  contractor.  Still  another  switch  selects 
use  of  either  calendar  attrition  or  operating  hours  in  estimating  Operating  and  Support 
costs. 

Cost  Estimating  Relationships 

The  model  contains  two  main  types  of  CERs,  those  which  are  embedded  in  the 
model  in  the  form  of  mathematical  statements  or  cell  formulas,  and  those  which  are 
inserted  as  specific  values  for  a  discrete  activity.  For  example,  in  the  E&MD  Contractor 
Support  and  Ser/ices  number  1  (EMD_SS1)  spreadsheet  row  for  estimating  the  cost  of 
Value  Engineering,  a  CER  takes  the: 

Input  value  from  LCCM  IN  for  the  percentage  of  the  total  system  which  is 
new  development,  and 

Multiplies  it  by  the  total  dollar  value  of  System  Engineering,  and 

Multiplies  it  again  by  the  percentage  of  System  Engineering  which  is  the 
Value  Engineering  share  (an  embedded  CER). 

We  obtained  this  CER  from  analysis  of  a  contractor  cost  data  report  (CCDR),  but 
we  recognize  that  we  have  to  expand  our  research  and  refinement  of  the  CERs. 

Computed  Statistics 

In  LCCM  IN,  the  master  spreadsheet,  we  have  established  databases,  particularly 
for  the  hardware  inputs,  and  generated  statistics  from  the  values  for  the  cabinet, 
component,  and  Lowest  Replaceable  Unit  (LRU)  quantities  and  costs.  These  computed 
statistics  are  used  in  the  PME  set  of  spreadsheets  to  develop  system  costs.  They  are  also 
used  in  the  Support  and  Services  spreadsheets  to  estimate  selected  support  functions 
such  as  System  Engineering. 

Functions 

We  developed  special  user  defined  functions  for  PROPHET  to  simplify  formulas  in 
calculating  learning.  While  not  an  input  in  the  sense  that  a  casual  user  would  insert  these 
functions  to  operate  the  model,  functions  have  been  installed  and  are  available  for  use 
anywhere  in  the  model.  Both  average  recurring  cost  (ARCLRN)  and  total  recurring  cost 
(TRCLRN)  functions  are  operative.  Further,  the  user  can  select  between  Cumulative 
Average  Cost  and  Unit  Cost  curves  (Wright  and  Thompson  curves)  by  inserting  the  digits 
1  or  2  in  a  designated  cell  (“switch")  in  LCCM  IN. 


FUNCTIONAL  USE 


Insertion  of  Variables 

The  first  step  in  use  of  PROPHET  is  to  open  the  Excel  application,  followed  by 
opening  of  LCCM  IN,  the  spreadsheet  where  inputs  are  entered.  The  user  can  scroll 
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through  the  spreadsheet  to  review  the  inputs  which  are  in  the  cells,  and  change  whichever 
values  are  needed  to  reflect  the  new  system  to  be  estimated.  A  sample  of  one  page  of 
LCCM  IN  concerning  system  quantities  is  shown  in  Figure  14.  The  first  scroll  through 
LCCM  IN  may  require  several  hours  to  ascertain  where  categories  of  values  are  located, 
but  frequent  use  speeds  up  the  search  process.  In  addition,  alt  the  normal  EXCEL 
functions  are  available,  such  as  FIND  “a  certain  string  of  characters”. 

Operation  of  PROPHET 

After  all  inputs  have  been  entered  in  LCCM  IN  the  user  can  sequentially  open  and 
close  each  phase  spreadsheet  in  sequence  and  then  the  report  summary  spreadsheets. 
This  sequence  of  opening  and  closing  spreadsheets  will  permit  the  input  values  for  that 
system/program  configuration  to  be  acquired  and  used  by  all  the  dependent  spreadsheets 
and  the  model  will  generate  an  updated  report  of  life  cycle  costs.  PROPHET  also  contains 
a  macro  executed  by  a  “RUN"  button  at  the  bottom  of  LCCM  IN  which  will  accomplish  the 
process  automatically  and  faster  than  a  human  operator  can  mn  the  model. 

If  a  new  report  format  is  desired,  the  user  can  quickly  create  a  new  spreadsheet  in 
the  appropriate  format,  and  then  invoke  links  in  the  desired  cell  format  to  the  estimated 
values  in  the  phase  or  collector  spreadsheets.  Future  operations  of  the  model  would  then 
automatically  update  the  values  in  the  new  report  if  it  is  opened,  either  with  the  source 
spreadsheets  opened,  or  by  a  positive  response  to  the  question,  “Update  external 
references?” 

We  havb  operated  this  prototype  tool  extensively  over  the  past  two  years  and  It  has 
performed  much  better  than  we  expected.  We  nave  observed  great  flexibility  and 
adaptability  to  conditions  beyond  what  we  originally  set  in  the  model.  We  have  learned  a 
lot  from  it.  That  isn't  to  say  we  haven’t  noticed  any  refinements  that  should  be  made,  and 
that  we  intend  to  make  in  the  next  generation. 


CONCLUSION 

The  use  of  commercial  spreadsheet  applications  and  more  powerful  personal 
computers  provides  cost  estimators  and  analysts  with  a  more  powerful  tool  than  any  they 
had  before.  The  tool  is  flexible  and  can  be  quickly  modified  to  meet  changing  input  or 
report  conditions.  Literally,  thousands  of  input  values  can  be  inserted  in  a  suitably 
designed  new  model. 

Adherence  to  the  newly  published  DoD  Manual  5000.4-M  guidance  coupled  with 
the  new  spreadsheets  and  computers  shapes  a  more  disciplined  and  effective  approach 
to  cost  estimating  for  defense  systems. 

The  next  biggest  hurdle  to  overcome  is  the  compilation  of  reliable  databases  and 
the  derivation  of  dependable  and  accurate  CERs.  We’re  starting  on  that  task  now. 
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